Domino 6.5.4 Fix Pack 3
February 18, 2006
IBM Lotus announces Domino 6.5.4 Fix Pack 3, the third release under a new Fix Pack strategy. IBM strongly recommends upgrading to the latest Fix Pack, since Fix Packs address a small percentage of defects that impact the broadest set of customers. This is a scheduled Fix Pack of a limited number of low-risk/high-impact fixes to help customers safely avoid known problems. Fix Packs are released periodically between Maintenance Releases to provide a greater level of stability for customer environments. Fix Packs go through the same level of fix, regression and interoperability testing that occurs with our Maintenance Releases. Domino 6.5.4 Fix Pack 3 is also cumulative, containing all of the fixes from Domino 6.5.4 Fix Pack 1 and 6.5.4 Fix Pack 2, and may be applied on any language version of Domino 6.5.4, 6.5.4 FP1 or 6.5.4 FP2.
All fixes in this Fix Pack have already been successfully deployed at customer sites. Fix Pack fixes are included in the next shipping Maintenance Release. Since 6.5.4 FP3 shipped between 6.5.5 and 6.5.6, some 6.5.4 FP3 fixes are in 6.5.5 and the remainder will ship in 6.5.6. Customers unable to upgrade to later Maintenance Releases will want to install Fix Packs to benefit from later fixes made to the product. By providing a small number of fixes, customers are able to accept fewer code changes with lower risk, allowing them to "patch" an older Maintenance Release until a more extensive upgrade to the current Maintenance Release is possible. Fix Packs may be downloaded from the web, but will not be distributed on CD.
While Fix Packs provide important fixes and IBM strongly recommends applying the latest Fix pack available for a Maintenance Release, IBM still recommends that customers upgrade to the latest Maintenance Release + Fix Pack combination to receive the broadest set of fixes available. You will receive more overall fixes with a later Maintenance Release + Fix Pack than with a set of Fix Packs on top of an earlier maintenance Release.
The following is a list of the problems fixed in this 6.5.4 Fix Pack.
1. There are 5 fixes below with a plus symbol (+) before the SPR number. This symbol indicates fixes for regression bugs. A regression bug is a bug that was introduced in a Maintenance Release that did not exist in previous releases of that code stream. For example, a bug that appears in R6.5.4 but did not exist in R6.5.2 is a regression.
2. Technote Numbers are displayed in parenthesis following the fix description.
3. All of these sprs are also fixed in 6.5.5 with the exception of these which are fixed in 6.5.6: RBRE6J7RYE, JPAI6JPM5K, JPAI6KCUCT, JPAI6KGSZ9, JDEN6CJMBV, RWAH6HPQ8B, CTOI68RDMH
- SPR# JDEN6CJMBV - Fixed a memory leak in LE. [TN# 1195931]
- SPR# CMCY5Z3RC6 - Fixed a memory leak in Replication. [TN # 1214950]
- SPR# ERYR6FEMZM - With this fix, the maximum number of servers supported in a single domain has been doubled. Also an error message will be displayed if the maximum number is exceeded. [TN# 1216813]
- SPR# JPAI6EFMP6 - Improved memory handling with concurrent NoteOpen transactions (from clients to the server). [TN# 1230050]
- SPR# TBOE66EL4C - Fixed a hang which occurred when Archiving, when "not modified" was less than 200 days. [TN # 1202124]
- SPR# BAKH5ZQH7H - Fixed an access violation trying to access shared memory structures.
- SPR# CTOI68RDMH - BulkDecRefCount() requests are meant to handle the automatic recycling of objects on the server after the corresponding java object has been finalized by the jvm on the client machine. In the problem scenario, the session object was being put on the list of objects that needed to be refcounted with the bulkDecRefCount request. This is wrong because the client does own the "keep alive" reference to the session. Technically the last reference is owned by the session itself. And it manages itself by taking into consideration a session->recycle() operation and whether the connection is still alive. So, when the bulkDecRefCount operation came in the "keep alive" reference was being handled in an abnormal way and this is why the reference count was off by one. The fix was to modify how bulkDecRefCount() is executed. [TN# 1196707]
- SPR# JDST6ATT89 - When Server task settings for the administration process indicate that "Store Admin Process log entries when status of no change is recorded:" is set to No, then all log entries are not displayed (Even those which indicate a database was modified as a result of the request). This fix will correctly display log entries when appropriate. [TN# 1225702]
- +SPR# JPAI6JPM5K - Fixed a server hang regression introduced in 6.5.4 FP2 and 6.5.5 with SPR NGRT67EGPM, "Improved memory handling with concurrent NoteOpen transactions (from clients to the server)". A fix was applied in 6.5.5 with SPR JPAI6EFMP6. This fix worked at a number of customer sites, however, when tested in house in Domino 7, additional problems were discovered. These problems have been resolved in SPR's JPAI6JPM5K, JPAI6KCUCT, and JPAI6KGSZ9. [TN # 1230098]
- +SPR# JPAI6KCUCT - Fixed a server hang regression introduced in 6.5.4 FP2 and 6.5.5 with SPR NGRT67EGPM, "Improved memory handling with concurrent NoteOpen transactions (from clients to the server)". A fix was applied in 6.5.5 with SPR JPAI6EFMP6. This fix worked at a number of customer sites, however, when tested in house in Domino 7, additional problems were discovered. These problems have been resolved in SPR's JPAI6JPM5K, JPAI6KCUCT, and JPAI6KGSZ9. [TN# 1230051]
- +SPR# JPAI6KGSZ9 - Fixed a server hang regression introduced in 6.5.4 FP2 and 6.5.5 with SPR NGRT67EGPM, "Improved memory handling with concurrent NoteOpen transactions (from clients to the server)". A fix was applied in 6.5.5 with SPR JPAI6EFMP6. This fix worked at a number of customer sites, however, when tested in house in Domino 7, additional problems were discovered. These problems have been resolved in SPR's JPAI6JPM5K, JPAI6KCUCT, and JPAI6KGSZ9. [TN# 1230052]
- +SPR# LHZO6H2CLE - Fixed a problem in the decoder where it wasn't updating a pointer when the buffer was reallocated. This problem was visible when (a) messages have over 40k of data in the text/html part, and (b) messages are being delivered to "Prefers Notes Rich Text" users. This regression was introduced in 6.5.4 FP1. Workarounds would be to change users mail storage preference to "Keep in senders format" to avoid MIME->CD conversion or use notes.ini MIME_CONVERT_HTML_TO_ATTACHMENT=1, which would place the HTML in an attachment which could be opened in a browser. [TN# 1220303]
- SPR# LOMI6AALJV - Fixed an intermittent Domino Server crash which occurred when an iNotes for Web Access user attempted to enable the Out of Office agent. The server reports an Insufficient Memory error message when it crashes. This issue can also be seen in cases where a server is in a low memory condition. The top four lines of the stack will show a PANIC in MemoryInit1. The root of the fix is the reuse of the MM structure. [TN# 1214762]
- SPR# LVAE6GLLN9 - This fix corrects a problem where a released buffer was used to copy the information for the object. [TN # 1218917]
- +SPR# MIAS6HQSYS - Fixed bad formatting which caused a server crash in UNK table code. This regression was introduced in 6.5.4 FP1. [TN# 1223996]
- SPR# MKIN6AXQ39 - For serviceability, URL history has been added for HTTP threads to memcheck output. To enable this feature, the Notes.ini variable "HttpDebugEnableHistory=1" must be used. [TN # 1230254]
- SPR# RBRE6B7NWR - This fix prevents MAPS from panicking with the error 'handle not allocated'. [TN # 1205474]
- SPR# RBRE6J7RYE - The public API NSFNoteExtractWithCallback used by 3rd party applications was not exported properly from the LIBNOTES srvpgm. This fixes the export so that 3rd party applications can call this API. [TN # 1225950]
- SPR# RGET5ZE2A7 - The DEBUG_SHARED_POOLS and DEBUG_PRIVATE_POOLS notes.ini settings have been modified to dump shared and private pools separately, as well as support other criteria.
- SPR# RWAH6HPQ8B - This fix allows daylight savings time and standard time changes without recycling the Domino server. [TN# 1224799]